The evolution of graphics rendering technology has led to the development of procedural techniques for describing various steps in the rendering process. Procedural geometry is useful as a mechanism for producing arbitrarily complex geometry from compact descriptions. For a simple example, a cube object can be represented passively, as a polygonal representation comprising a list of eight vertexes and six sides. However, a more-compact procedural representation can be developed where the cube becomes the result of a cube-generating procedure, which needs as input only position coordinates and a size. In another example, curves can be described according to Bézier control points, allowing a complex path to be mathematically described with only a few data points. Thus, geometric procedures often provide a useful, compact way to represent shapes, avoiding the access and transfer of many points of data. More complex procedures, such as rotations or splines, offer even greater compression of data. Other processes, such as shading and texture also take advantage of procedural techniques. Indeed, programmable procedural shaders are seen by some as a most efficient way to tackle graphical rendering problems. Such processing maps well to a Single Instruction, Multiple Data (“SIMD”) architecture; allowing hardware vendors to exploit parallelism and achieve high performance.
However, conventional graphics display or graphics processor unit (“GPU”) architectures enforce a divide between procedural geometry and procedural appearance (such as procedural shaders and texture) by means of a processing chain that operates on fixed, passive polygonal primitives. A common approach is to relegate procedural geometry to the prerasterization stages, to expand the procedures into polygons, and to devote a large amount of bandwidth to feeding polygons to the transformation and setup stages of the graphics processor.
These limitations can lead to visible and undesirable artifacts and have constrained procedural advances from aiding in level-of-detail (“LOD”) management. LOD management is needed to avoid under sampling, or tessellation, artifacts when a curved surface is viewed up close, and to avoid wasting resources, both temporal and spatial, when a densely triangulated surface is viewed from afar. These difficulties are especially prevalent when dealing with changes in resolution when zooming in on shapes.
As an example, consider rendering a surface which is rendered using a triangle mesh. One solution might be to densely sample the surface, forming many more smaller triangles and computing pixel color accordingly. An alternative might be to utilize a lower density mesh. While both of these approaches will work, the first will waste resources if the surface is viewed from a distance, and the second will introduce sampling artifacts under zoom.